Skip to main content

Windows Defender or other security solutions may flag Cyberhaven DLL's

Summary: Security solutions like Microsoft Defender or CrowdStrike use behavioral analysis and heuristic scanning to detect potentially suspicious activity. This includes monitoring when dynamic libraries (DLLs) are injected into processes or loaded from unexpected locations. Question_md: Defender is blocking the latest version of Cyberhaven DLL.

Answer_md: Common reasons Defender may flag Cyberhaven DLL's: The different behavior between fresh install and upgrade.

Windows Sensor Processes and Paths for exclusions customers should have for their EDR tools: https://docs.cyberhaven.io/docs/windows-sensor-processes-and-paths

  1. Temporary MSI Install Locations: When Cyberhaven is UPGRADED via MSI, the Windows Installer (msiexec.exe) creates temporary working directories under "C:\Windows\Installer\MSIxxxx.tmp"

  • In these temporary directories, the installer extracts certain DLLs — for example:

    • CyberhavenInstallerActions.dll — custom-action DLLs that execute logic (like service registration, cleanup, or version checks) during upgrade routines.

  • These DLLs are then executed by rundll32.exe from the temporary directory as part of the upgrade process as shown in the screenshot below from a procmon trace during an upgrade.

  • These locations are often monitored by Defender, as some malware often uses similar staging techniques.
    https://cyberhaven.file.force.com/servlet/rtaImage?eid=ka0Nt00000048rp&feoid=00NNt0000026ms1&refid=0EMNt00000BPwld

  1. Rundll32.exe usage: Cyberhaven's installer actions leverage rundll32.exe to execute installation tasks as mentioned above. Defender can flag rundll32 usage combined with DLLs in temp folders as a suspicious pattern, even though it's part of a legitimate MSI install behavior.

  2. Unsigned DLLs: During upgrade under the temporary directory; Cyberhaven DLL's will show unsigned. For example; CyberhavenCommon.dll can be seen at the beginning during the initial upgrade (Unsigned at this point) - and the same DLLs will appear properly singed in the final installation directory (ProgramFiles). This is known and a Jira issue has been created as PROD-7643